Ethernet-APL Simplifying Device Connection
Published on : Sunday 03-01-2021
Jonas Berge explains how converged IP-everywhere in the field simplifies device connection.
Imagine at any time being able to connect an additional sensor, video camera, infrared thermal camera, 3D LiDAR, on-off valve, HMI panel, weighing scale, power meter, or package unit controller anywhere in the plant with just a short two-wire patch cord to the nearest junction box in a process unit. Today such devices use different signals: 4-20 mA, video baseband signal (VBS), Cat 5 Ethernet, on-off, Modbus/RTU, and Profibus-DP, etc., connecting to different signal wire infrastructure which may not be close at hand making deployment of additional devices a challenge. With Ethernet-APL all these kinds of devices can share the same advanced physical layer (APL) network infrastructure across the plant, making additional deployments easy.
So, what does APL mean for the next generation of plants?
Mixed signals
Building five or more signal infrastructures – cables, cable tray, and junction boxes – for the plant as done today is complex and costly. Since many of these signal types are not intrinsically safe, explosion proof or flameproof installation is instead required, which is costly. There may even be multiple Modbus networks for each vendor as Modbus devices tend not to share the same network.
Similarly, deploying additional devices in a plant years after the control system and other systems were originally installed is also costly. In many cases the required signal infrastructure may not be available in the vicinity, so if you want to deploy for instance an infrared camera for leak or spill detection, an advanced sensor, or a gas analyser, the right signal infrastructure has to be extended such that VBS video signal, Modbus, or whatever can be backhauled to wherever it needs to go.
In the office, Ethernet has slowly taken over not only the computer networking between workstations, servers, and multi-function printers, etc., but also phone systems, closed circuit television security cameras, video conferencing systems, and even video walls. The result is a single signal infrastructure for all kinds of office devices and systems. Deploying additional office devices is easy as they share the same Ethernet infrastructure.
This sets an example for what Ethernet in the field could be like.
Ethernet-APL for the field
Most control systems already use regular Ethernet (Cat 5) in the marshalling room and control room for the I/O subsystem, controllers, servers, and workstations. Regular Ethernet is not suitable for the field, so therefore Ethernet-APL must be used instead. The vision for Ethernet-APL is a converged IP-everywhere, all-Ethernet network where process units only require a single simple wiring infrastructure and where data from all kinds of devices share the same single Ethernet-APL infrastructure. The expectation is that Ethernet-APL will take the place of everything in the field for new plants and in place of the mixed signals of the past, just like Ethernet took the place of everything in the office. That is, control, safety, monitoring, video, and power existing on the same two wires – a single multi-purpose network.
This will result in savings, particularly with intrinsic safety. And it becomes easy for instrumentation and control engineers to add all kinds of devices as an afterthought any time in the future as the Ethernet-APL infrastructure will be ubiquitous across the plant so there will always be an APL field switch somewhere nearby where you can connect. This vision mimics the IP-everywhere Ethernet convergence we have seen in the office. This ability to easily add on sensors and other devices is key to digital transformation, digitisation, digitalisation, Industry 4.0, the Fourth Industrial Revolution, or whatever you prefer to call it.
That is, sensors, video cameras, infrared cameras, on-off valves, HMI panels, weighing scales, power meters, and small controllers in the field will all be IP devices. When everything is an IP packet it can all share the same Ethernet-APL infrastructure for all kinds of devices in the field. A reduction from 5 or so different kinds of hardware infrastructures down to a single hardware infrastructure will result in savings on shared cables, junction boxes, and marshalling.
Non-exclusive protocols
For traditional bus protocols like Fieldbus, Modbus/RTU, Profibus-DP, and HART®, etc., the network is exclusive; all devices are FOUNDATION fieldbus, all Modbus, or all are Profibus. For bus it is always a single protocol, never a mix on a network.
Ethernet, and therefore also Ethernet-APL, is different. It is non-exclusive, meaning there is a mix of application protocols in use. That is, there is a mix of devices communicating FOUNDATION Fieldbus high speed Ethernet, HART-IP™, Modbus, and PROFINET communicating at the same time. Many devices supporting multiple protocols, serving multiple applications at the same time using different protocols. And not only that, there will be many devices using non-automation protocols at the same time.
Digital video cameras use real-time transport protocol (RTP) or real-time streaming protocol (RTSP). That is, there is no PROFINET video camera or HART-IP infrared camera, but a video camera or infrared camera that shares the same Ethernet-APL network as PROFINET-IO and HART-IP devices. You probably would not put perimeter security video cameras on APL, but APL video cameras may be used for process video like flare monitoring, reading drum labels, rotating kiln, and incinerator operation monitoring. That is, a mix of devices, providing a mix of data, using a mix of application protocols will share the same Ethernet-APL network. Therefore, many of the new innovative devices you will see on an APL network will not use HART-IP or PROFINET-IO, but they all share the same network.
Not all devices on the network need use the same protocol. Not even all the instrumentation. A transmitter using HART-IP and a valve using PROFINET-IO can be part of the same control loop, but the controller in between must be able to handle both protocols.
Virtual marshalling
Note that not all the data on the APL network is communicated to the distributed controls system (DCS) or the historian because not all devices are related to process control. Process control data goes to the DCS, but, for instance, video does not have to go to the DCS or historian. Video packets will likely go to video management software or a simple digital video recorder – and it may go to DCS operator workstations or a video wall from there. That is, packets are switched to the DCS, historian, VMS, or other destination. The network management for the Ethernet-APL network must manage bandwidth to make sure latency is not introduced for process control and safety functions.
Plants are already being designed to use Ethernet-APL even though devices are not yet available. If you are designing a plant right now, it may be a good idea to investigate using Ethernet-APL as the converged IP-everywhere, Ethernet-everything, signal transmission for the field.
Jonas Berge is a Subject Matter Expert in digital transformation in the process industries, technology adoption, and digital architectures including dashboards, analytics, software interfaces, historian platforms, wireless instrument networks, fieldbus, intelligent device management, digital ecosystems, and Industrial Internet of Things (IIoT). He is currently the Senior Director for Applied Technology for Emerson's automation solutions business in Asia Pacific. Jonas has over thirty years of experience in the field of instrumentation and controls. Jonas is a senior member of ISA, participating in the ISA104 and ISA108 standards committees and sits on the Steering Committee of the FieldComm Group in Asia Pacific. He is one of the architects of FOUNDATION fieldbus. He is the author of the book ‘Fieldbuses for process control: Engineering, Operation, and Maintenance’. He is the editor for the ANSI/ISA/IEC/TR 61804-6 standard. He holds patents in safety communications and received the 1999 ISA award for excellence in documentation.
